Amiga Tools 3

home *** CD-ROM | disk | FTP | other *** search

/ Amiga Tools 3 / Amiga Tools 3.iso / grafik / raytracing / rayshade-4.0.6.3 / inetray / readme < prev next >

Wrap

Text File | 1993-08-15 | 10.6 KB | 253 lines

====================================================================== R E A D M E doc: Fri Mar 6 16:04:58 1992 dlm: Wed Jul 21 14:38:30 1993 (c) 1992 ant@ips.id.ethz.ch uE-Info: 37 16 NIL 0 0 72 3 2 8 ofnI ====================================================================== NOTE: Read the file RELNOTES for a short description of the changes since the last version. NOTE: The email address listed in most file headers is an obsolete one. The correct address is ant@bernina.ethz.ch Whatis Inetray -------------- Inetray is an application allowing you to concurrently raytrace an image using a lot of machines. The task is dynamically distributed to all machines offering this service. Requirements ------------ You need the following software libraries to run Inetray: - BSD-style sockets - SUN rpc-library (at least version 4.0) - SUN xdr-library (at least version 4.0) - rayshade 4.0.6 (or later, but must be compatible) The only thing you probably need to check is if you have the SUN rpc-library since this uses the other two communications libraries. On all machines where you want to run servers, you need to have a local portmapper running. Documentation ------------- README This file POO Principles of operation; some internals INSTALL compilation & installation manual SUPPORT supported machines and quirks FAQ Frequently asked questions HISTORY A short program history (patches, releases, ...) TODO Things to do (Todo que nunca voy a hacer...) RELNOTES Release notes Examples -------- Any rayshade examples work, but I included an image which uses lots of CPU time to calculate. It's called mole.ray. Copyright --------- Feel free to copy the software for non-commercial purposes. Note, however, that this software is not GNU; this means that it was never intended to be a monster and I will not allow it to become one. Author ------ Andreas Thurnherr (ant@bernina.ethz.ch), currently probably travelling somewhere. Support ------- I will try to give limited support to people trying to port Inetray to new machines; you can mail me to the address given above. Please read the docs before mailing me. Credits ------- I'd like to thank the people of IPS for allowing me to use their machines for the development of Inetray - parts of it was also developed during work hours. Furthermore, I'd like to thank the team of active beta-testers (David DeBry, Marvin Landis, Michael Graff, Benny Yih and Rick Braumoeller - I sure hope I didn't forget anybody) for sticking with me thru all the 0.X.X versions, bugs and features. Special thanks to Nikolaos Fotis from Greece who wanted everything, refused to read the docu and really influenced the user friendliness a lot. For version 2 I thank the people of CSCS for letting me basically do whatever I wanted. Components ---------- Inetray consists of the following executables: inetray the frontend dispatcher; the client rpc.inetrayd the worker; the server inetray.ping pinger to check response of servers inetray.kill killer; kills all running servers inetray.start startup daemon for rpc.inetrayd rpc.dereg deregister utility for SUNRPC netinfo prints all network addresses of local host irstart starts inetray.start servers on remote hosts generr simulate an error message of a worker Terminology ----------- The terms worker and server both refer to rpc.inetrayd. The server is the parent, servicing RPC requests; the worker is the child doing the actual work. The terms dispatcher and client both refer to inetray. Runtime Errors -------------- NOTE: Error messages are collected and handled on a per-worker base. After a non-successful run you should check the messages files on all workers behaving strangely!!! Inetray error messages fall into two classes: those generated by inetray and those generated by the rayshade libraries. Inetray tries to write both classes to the same place: either the syslog messages file or a messages file in the temp area of your installation (you can run generr to find out). This is only possible if your machine correctly supports asyncronous I/O using a socketpair. If this cannot be done then the errors generated by the rayshade libraries are written to a file in the temp area - if this is the case then Inetray writes a note to the messages file telling you where the rayshade errors have been written to. Inetray, upon startup, tries to figure out if your machine handles asyncronous I/O correctly and writes a warning to your messages file if that doesn't work. In that case you should recompile inetray with the NOASYNCIO_QUIRK (see SUPPORT for details). Input ----- Rayshade takes its input either from stdin or from files. The stdin is distributed to all servers before rendering starts. Input can come from a number of files; if this is the case then the files (or a copy thereof) must be accessible from all the worker machines. The most convenient place to put all input files is in any directory under the home directory of the user which exists on all machines (e.g. if the directory $(HOME)/inetray exists on all machines then the .ray files can be put there (may involve copying). Note that any part of the path may be a link; when using NFS copying should not be required. The exact rules for finding the files are described in POO. Note that even if input is coming from stdin (pipe or stdin redirection) there are two possibilities that files must be accessed: a) when the #include CPP diretive is used and b) when rendering heightfields. Those files must be accessible on all worker machines as well. Random Numbers -------------- On different architectures, the random generator used by rayshade 4.0 may generate different sequences. This problem has to be fixed in rayshade since I won't change any code in those libs. I think it will be fixed in the next release. inetray [params] ---------------- is supposed to be compatible with ``rayshade''. When you start it up, it replies by giving a Session Key (see POO for details), followed by the list of servers which replied. The list is composed of the following fields: inet number : Internet address of remote machine remote version : Version of remote rpc.inetrayd hostname : Name of remote host (or, rather, primary interface) remote pid : Pid of remote server (workers are forked from this) username : Effective user id on remote machine remote directory: Working directory on remote machine After that the total number of workers is given followed by scheduling information. After the trace has been completed a sorted statistics is printed. You can get to this statistic any time during the trace by hitting ^C (i.e. interrupting it with SIGINT). Interrupting it again while nothing has changed, gives you the option to abort the program orderly. Note that hitting ^C when inetray is part of a pipeline or has been started from within another program (like make) changes this behaviour. Then, it is shut down immediately. If inetray terminates without an orderly shutdown, you'll probably have to issue an inetray.kill to kill all workers and servers. If you don't do that, the servers will shut themselves down after approximately 1 minute. rpc.inetrayd ------------ is the server-daemon. It is started either by inetd or by inetray.start. On receiving a request, it forks a worker and continues waiting. There can, however only be one request outstanding any one time. Roughly once every minute the server checks if the dispatcher is still running. If that's not the case, it kills its worker (if it exists) and exits with an error message in the syslog. At the same time it checks if its worker has exited with an exit code not equal zero; if one is detected (i.e. rayshade library exit or dead due to a signal) it shuts itself down orderly too. NOTE: you never start this program from the command-line (see INSTALLATION to find out how you DO start it) inetray.ping [Use List] ----------------------- is a pinger utility. It checks if servers are ready to run for you. To find out, if a specific server is ready to run, you just write ``inetray.ping hostname'', if you want to check which workers are ready to run, you run inetray.ping without any arguments. The argument list can be arbitrarily complicated. Example: ``inetray.ping foo UID=12, bar, 124.130.34.0 N=2 UID=13, \ local N=0, multi N=16'' See Appendix B in INSTALL for details about the Use List. inetray.kill [key] ------------------ kills all running servers even if they're currently computing. Since killing works only with the correct session key, inetray.kill needs to have this key. Usually it takes it from .inetray.key in the current directory. This file is written by inetray. You can, however, supply your own key (to override .inetray.key) by supplying it on the command line. This utility can be used for a clean shutdown. It can be used while inetray is still runnning; inetray notes that all the servers have died and exits in the end. inetray.start [path of rpc.inetrayd] ------------------------------------ starts rpc.inetrayd (one or more) on request. Another method is to have them started by inetd. See INSTALLATION for details. Note that there can only one inetray.start be running on any one host at any one time. rpc.dereg [prognum versnum] --------------------------- deregisters the indicated program/version with the local portmapper. Note that the same functionality is offered by rpcinfo(8) but it requires root privileges (another great show of SUN security) netinfo ------- prints a list of all network interfaces, local addresses and broadcast addresses installed on the local host. If the host is set up correctly, it should react to all addresses given. Actually only the inet interfaces which listen to broadcasts are printed! Note that if netinfo shows more than one interface, the machine is a gateway; you should not run inetray (the dispatcher) on a gateway since it produces lots of traffic on both networks! irstart [pattern] ----------------- searches the current .inetrayrc for lines containing the pattern. Of these lines it selects the ones starting with ``#@''. These two leading characters are removed and the remainder of the line passed as a command to /bin/sh. The practical abshot of all this is that you can use irstart and your .inetrayrc file to start remote inetray.start servers. Hosts which already have an inetray.start running are handled correctly. generr ------ simulates a rayshade error message. You should run this program to determine if you compiled inetray with the correct quirks. After you've run this program, you should try to find the errors on the machine (generr tells you where). Note that you should run generr on all workers to be shure no error message gets lost.